「Scrum 說每個 Sprint 結束，都應該有可以使用的新功能釋出，如果一個 Story 在一個 Sprint 中做不完，該怎麼辦？」

這是個 Scrum 團隊會遇到的家常便飯，我曾經指導過的團隊，對這個狀況，有兩種不同的處理方式：

1. 減法：在 Planning 時，只挑 Story 中可以 Demo 的項目實作，或是把價值較低的項目直接略過
2. 延長 Sprint 時間：遇到比較大的 Story ，動態的調整 Sprint 時間成 1 ~ 4 週

我一貫強調管理與開發方法，沒有標準答案，只要開發系統可以穩定帶來價值，團隊成員可以持續成長，任何方法都是好方法。而上述的方式，在實際運作的團隊中，可能會發生以下的副作用：

1. 交付型專案不存在根據價值排除的開發項目，或是在產品專案中，不存在可以刪去的功能或設計。
2. 不穩定的開發週期，團隊對 Scrum 活動時間點容易混淆。

今天的文章，來聊聊在我提出的開發系統中，這個狀況可以如何應對。

培養團隊的肌肉記憶

最好的方式，就是建立週期性的 「Scrum 活動」與穩定的「Sprint 開發周期」，簡單來說，就是有一個固定的 Scrum 行事曆，如下圖。

這樣做的好處，是團隊成員可以慢慢形成一種工作的節奏，例如那些天可以有最專注的時間，哪些天需要開會，哪天前需要把估點搞點。這根本不用教，幾個 Sprint 後，就會形成習慣。另外，有些團隊太過依賴 Scrum Master 的存在，沒有他，連開會都會忘記。我卻認為一個漸漸形成的自組織，慢慢的就不需要 Scrum Master 出現在每場會議中，Scrum Master 可以專注在挖掘更深層的系統問題和引導技巧。而到達這個狀態，有節奏感就很重要。所以第一個原則是，不要隨意延長開發週期。

Scrum guide 沒把話說死

那 Story 的大小超過了一個 Sprint 的工程量能怎麼辦？很簡單，就是下個 Sprint 繼續做。而完成的項目，雖然還不能提供使用者使用，但也可以算是「產品增量」(Increment)。來看看 Scrum Guide 是怎麼說的：

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint.　- Scrum Guide 2017

The increment must be in useable condition regardless of whether the Product Owner decides to release it.　　- Scrum Guide 2017

文中的「potentially」其實就可以解讀成：Sprint 的結束，不一定要交付出可以給使用者可完整使用的新功能，只要確保完成的項目是可用的產品增量即可。

在 2020 修訂版中，又進一步的抽像化描述：

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. - Scrum Guide 2020

「any aspect」我的解讀是：不一定是用戶可操作使用的功能才算 Increment ，舉凡基礎架構的搭建、模組化的實作、API 串接，對後續有相依性的功能來說，是「可用的」 (usable)，即滿足 Scrum 精神。

沒做完的項目 = 最高優先項目

由於每個開發項目都帶有點數， PM 可以直接將沒有完成的 Task ，放進下個 Sprint 中，只要把 Sprint 的工程量能，減去上個 Sprint 的殘留點數，就可以再將新的 Story 進 Planning 會議中。一切以完整的產品價值為優先考量，方法論不應該侷限商業價值的交付。

今天的分享就到這邊，明天繼續戰鬥！